Re: [Mono-dev] Porting Mono to 'asm.js'
https://github.com/xen2/SharpLang 2015-03-15 12:59 GMT+03:00 Nirmal Lankathilaka nir3al+...@gmail.com: I've been using Mono for developing desktop apps for a couple of years and would love to contribute to the project. Since I'm still a student, I think GSoC is a splendid opportunity to start. Porting Mono to `asm.js`, presented for GSoC, caught my attention recently. I spent some time researching this and I'd like some clarification from the community: Since Mono-LLVM support does exist[mono-llvm] http://www.mono-project.com/docs/advanced/mono-llvm/, why would the need arise for a port? I understand that there are limitations [mono-llvm#limitations] http://www.mono-project.com/docs/advanced/mono-llvm/#limitations in the above approach as LLVM doesn't fully support all the needs of Mono; but since there is no specifications given which would require one to avoid the above approach (mono-llvm--llvm--emscripten--asm.js), I'm a bit confused. On a different note, could you explain to me whether I should use the forums instead of the mailing-lists (which I prefer) for communication regarding GSoC and the `asm.js` port. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] proxygen bindings
Hello. Have you guys heard of the proxygen ( https://github.com/facebook/proxygen/ ) - an HTTP stack library recently released by Facebook? It supports HTTP, SPDY, websockets and will support HTTP/2.0 later. I was playing around with it and created some initial bindings that allow to write code like this: https://github.com/kekekeks/prowingen/blob/master/managed/Sandbox/Program.cs It performs rather good, I've got 41K requests/sec on my laptop, but obliviously needs a lot more work for production use. 1) Is anyone interested in this sort of thing? I was initially planning to implement an OWIN server on top of proxygen, but now I'm not so sure, since I'm currently using my wrapper to libevent's HTTP server ( https://github.com/kekekeks/evhttp-sharp/ ) and quite happy with it's performance which is almost the same (up to 38K rps on the same machine, both benchmarks without thread pooling). The only thing it lacks is websocket support, but I can live with that. Proxygen also can't be compiled for Windows platform at all, so that server will be mono-only. 2) Does anyone have benchmark data on Kestrel? When I hammer it with ab or wrk it just hangs and stops responding to any requests. If it can keep up with proxygen in terms of performance, such bindings would be useless. 3) Is there any way to speed up interop calls? When I replace C++ handler implementation with managed one that does essentially the same thing, the performance drops drastically, i. e. from 130K to 40K rps). Currently I'm using COM as a bridge ( with some basic infrastructure native-managedimplementation - https://github.com/kekekeks/prowingen/blob/master/native/include/com.h ). Is there a better way? Regards, Nikita ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] proxygen bindings
I figured out that the most costly thing is the creation of 2 RCW (Runtime Callable Writer) per request. As long as I don't spam COM object instances it should be fine. Althrough it wouldn't be really COM-way for request/response objects. 2014-12-03 23:29 GMT+03:00 Rafael Teixeira mono...@gmail.com: I would say in the interop calls, you'll need to drop COM and implement custom marshalling to avoid messy copying/conversion of structs and strings (CLR uses UTF-16 strings internally and I didn't dig into proxygen or your COM wrapper to see what it uses, but probably it is utf-8 or some multi-byte encoding, so at least some conversions will be needed) On Wed Dec 03 2014 at 3:59:40 PM Nikita Tsukanov kek...@gmail.com wrote: Hello. Have you guys heard of the proxygen ( https://github.com/facebook/proxygen/ ) - an HTTP stack library recently released by Facebook? It supports HTTP, SPDY, websockets and will support HTTP/2.0 later. I was playing around with it and created some initial bindings that allow to write code like this: https://github.com/kekekeks/prowingen/blob/master/managed/Sandbox/Program.cs It performs rather good, I've got 41K requests/sec on my laptop, but obliviously needs a lot more work for production use. 1) Is anyone interested in this sort of thing? I was initially planning to implement an OWIN server on top of proxygen, but now I'm not so sure, since I'm currently using my wrapper to libevent's HTTP server ( https://github.com/kekekeks/evhttp-sharp/ ) and quite happy with it's performance which is almost the same (up to 38K rps on the same machine, both benchmarks without thread pooling). The only thing it lacks is websocket support, but I can live with that. Proxygen also can't be compiled for Windows platform at all, so that server will be mono-only. 2) Does anyone have benchmark data on Kestrel? When I hammer it with ab or wrk it just hangs and stops responding to any requests. If it can keep up with proxygen in terms of performance, such bindings would be useless. 3) Is there any way to speed up interop calls? When I replace C++ handler implementation with managed one that does essentially the same thing, the performance drops drastically, i. e. from 130K to 40K rps). Currently I'm using COM as a bridge ( with some basic infrastructure native-managedimplementation - https://github.com/kekekeks/prowingen/blob/master/native/include/com.h ). Is there a better way? Regards, Nikita ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] proxygen bindings
I've removed that RCW creating (i. e. I'm receiving IntPtr from native code) and now its 109K rps. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] a set of tests to find out the difference between .Net and Mono implementation (Mono-devel-list Digest, Vol 113, Issue 25)
If you really mean to execute an arbitrary file (Process.Start(foo.xlsx) will open foo.xlsx in Excel, on Windows, for example) then call /usr/bin/xdg-open thing - this is probably the most useful use-case, and is also valid when thing is a URL, opening in the default browser. AFAIK, xdg-open is used by Mono implementation of Process.Start if UseShellExecute=true (which is default). It's same on Windows - CreateProcess doesn't start Excel, it returns you an error, while ShellExecute does. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Debugging on a remote (non-Android) Linux Device
$ export MONODEVELOP_SDB_TEST=1 $ monodevelop Open the project you want to debug, Run-Run With...-Custom Command Soft Debugger,Listen Then run mono on your remote machine with --debugger-agent=address=YOUR_HOST_WITH_MONODEVELOP:1 2014-09-10 9:22 GMT+04:00 Bryan Crotaz bryan.cro...@silvercurve.co.uk: I have exactly the same issue on raspberry Pi. SSL fails about 50% of the time. And I don't know how to do remote debug either. Bryan Crotaz Silver Curve On 10 Sep 2014, at 03:45, Chris Tacke cta...@opennetcf.com wrote: I have a Mono project that mirrors a desktop project (same code, same projects, etc). Most development and debugging is done in Visual Studio and the Linux/Mono deployment is done on the build server with a command-line call to compile the Mono build. Generally speaking this all works just fine. Occasionally, however, we find behavioral differences between the .NET Framework and Mono. For example, right now I have code that works fine on the desktop, but under Mono it's failing (it's a socket call out to SSL, and yes, I've added a handler for ServicePointManager.ServerCertificateValidationCallback as a test but it still fails). When I run into these types of problems, I use Xamarin Studio to add in Console.Writeline calls, build, copy via USB, reiterate cycles and try narrowing the problem down. It's extremely slow and painful. Xamarin Studio can connect and live debug against iOS and Android. Is there a way to configure Xamarin Studio (or Visual Studio) and my Linux device to do the same? I would suspect that someone out there has tried debugging against a Raspberry Pi or something and this would be an analogous situation. If it matters, the Mono build I'm using is not off-the-shelf - I had to compile it myself since we're targeting the i586-cored Quark processors. I used to have a license for both Xamarin iOS and Xamarin Android, but really we don't target those devices so I let them lapse. I'm hoping that the debugging pieces aren't wrapped up in those. -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Debugging on a remote (non-Android) Linux Device
https://github.com/mono/monodevelop/blob/master/main/src/addins/MonoDevelop.Debugger.Soft/MonoDevelop.Debugger.Soft/CustomSoftDebuggerEngine.cs - It's implemented here, dunno why it's not enabled by default. 2014-09-10 11:19 GMT+04:00 Nikita Tsukanov kek...@gmail.com: $ export MONODEVELOP_SDB_TEST=1 $ monodevelop Open the project you want to debug, Run-Run With...-Custom Command Soft Debugger,Listen Then run mono on your remote machine with --debugger-agent=address=YOUR_HOST_WITH_MONODEVELOP:1 2014-09-10 9:22 GMT+04:00 Bryan Crotaz bryan.cro...@silvercurve.co.uk: I have exactly the same issue on raspberry Pi. SSL fails about 50% of the time. And I don't know how to do remote debug either. Bryan Crotaz Silver Curve On 10 Sep 2014, at 03:45, Chris Tacke cta...@opennetcf.com wrote: I have a Mono project that mirrors a desktop project (same code, same projects, etc). Most development and debugging is done in Visual Studio and the Linux/Mono deployment is done on the build server with a command-line call to compile the Mono build. Generally speaking this all works just fine. Occasionally, however, we find behavioral differences between the .NET Framework and Mono. For example, right now I have code that works fine on the desktop, but under Mono it's failing (it's a socket call out to SSL, and yes, I've added a handler for ServicePointManager.ServerCertificateValidationCallback as a test but it still fails). When I run into these types of problems, I use Xamarin Studio to add in Console.Writeline calls, build, copy via USB, reiterate cycles and try narrowing the problem down. It's extremely slow and painful. Xamarin Studio can connect and live debug against iOS and Android. Is there a way to configure Xamarin Studio (or Visual Studio) and my Linux device to do the same? I would suspect that someone out there has tried debugging against a Raspberry Pi or something and this would be an analogous situation. If it matters, the Mono build I'm using is not off-the-shelf - I had to compile it myself since we're targeting the i586-cored Quark processors. I used to have a license for both Xamarin iOS and Xamarin Android, but really we don't target those devices so I let them lapse. I'm hoping that the debugging pieces aren't wrapped up in those. -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] A few mono issues
1) You have to map your DllImport to corresponding *nix libraries. I.e. there is no such thing as gdi32.dll there 2) Mono's System.Drawing is quite limited, since it's just a bridge to Cairo library. You can't use high quality smoothing and image scale algorithms for example Consider using imagemagick instead. Regards, Nikita 2014-07-09 22:01 GMT+04:00 JamesSouth james_so...@hotmail.com: Hi all, I run a fairly successful .NET open source library called ImageProcessor that I am trying to port to Mono. Most things are now working except for two issues. https://github.com/JimBobSquarePants/ImageProcessor/issues/64 https://github.com/JimBobSquarePants/ImageProcessor/issues/64 I can't seem to get my animated gif encoder working on Mono (It produces a single frame) and I can't get dllimport working. (I get not found exception). Fixing these is beyond my current ability and I am looking to get some help from the resident experts here in order to get my release out of the door. I've built something that thousands of people use to make their development lives easier and I'd like to do more across different environments. Thanks james -- View this message in context: http://mono.1490590.n4.nabble.com/A-few-mono-issues-tp4663283.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and ASP.NET vNext
I suspect that having libuv behind socket code won't help much, since most
of socket performance problems are related to the fact that
BeginSend/Recieve, event loop and AsyncCallback run in different threads.
Because of that we have overhead even with simple
void ReadNext()
{
_socket.BeginRecieve(buf, blablabla, res=
{
_socket.EndRecieve(res);
ReadNext();
});
}
On windows that works fine because of IOCP behind that abstraction that is
designed to be used with thread pool. *nix platforms doesn't have anything
like IOCP, only epoll/kqueue, so for actual performance improvement one
have to use single-threaded approach (with round-robin connection dispatch
between workers), when all I/O operations and event loop run in single
thread.
2014-05-15 20:55 GMT+04:00 Miguel de Icaza mig...@xamarin.com:
Hello,
Well, i want to see a prototype, and then decide.
So this needs to be done with some kind of peer framework where this is
done.
On Thu, May 15, 2014 at 9:29 AM, Greg Young gregoryyou...@gmail.comwrote:
Yes I would say moving both to libuv would be a good move :)
On Thu, May 15, 2014 at 4:22 PM, Roope Kangas ro...@grandcrugames.comwrote:
Hi,
On a tangent...
It would be really nice if something like libuv would the thing behind
Socket code.
Could that be something to investigate?
Mono could basically piggyback on nodejs development.
--
Roope Kangas
On 15.5.2014, at 15.00, Greg Young gregoryyou...@gmail.com wrote:
So the one issue I have seen with the libevent implementation is that it
seems to perform very poorly in windows (+-5k hello worlds/second where as
its closer to 100k/second in linux). From researching libevent they
supposedly now use IOCP in windows and should be better but I have not been
able to make this happen. It may also be worth looking at libuv which is
pretty close to a drop in replacement for libevent as it seems to get much
better performance in windows and similar performance in linux. @Nikita I
will hopefully have some time next week and likely will send some more pull
requests in relation to the memory allocation patterns.
On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza mig...@xamarin.comwrote:
Hello Nikita!
Your approach looks fabulous! I look forward to trying it out!
Miguel
On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov kek...@gmail.comwrote:
I'll try to implement OWIN host on top of my libevent built-in http
server ( https://github.com/kekekeks/evhttp-sharp ) since for now
it's the fastest thing for handling HTTP-requests on Mono I know (now it
has host implementation for NancyFx which we are using in production for
half of a year).
Although both evhttp-sharp and FastCGI servers like HyperFastCGI and
Fos, are incapable of serving websockets (one because of underlying
implementation, another because of limitations of FastCGI protocol), so it
would be great to wrap something like
https://github.com/kekekeks/evhttp-sharp which has websocket support
and positioned as evhttp drop-in replacement.
Regards,
Nikita
2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
Wow! This is such great news!!
As for running Owin applications with Unix HTTP servers, I've
developed Fos http://github.com/mzabani/Fos on a very permissive
license and a focus on good documentation and running with Mono on *nix.
I
would very much love getting contributions on this, because my spare time
is running lower these days.
Hope it helps,
Marcelo.
On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza mig...@xamarin.com
wrote:
Hello guys!
Microsoft has open sourced ASP.NET vNext:
http://github.com/aspnet/home
This is an entire new web stack that only needs the core of Mono
(does not even use System.Web.dll!).
So these are of course great news, because (a) The core Mono has
been in active development, and (b) that means that Mono's on the server
can be used without all those pesky limitations that have been plaguing
us
for years.
So we ran into a couple of limitations in Mono: some classes that
they need are not implemented (I filed a bug, and a couple of Xamarin
folks
decided to take on that on their copious spare time) and we have a
couple
of bugs on FileSystemWatcher on OSX.
But this is a great time to:
- Get involved with the github.com/aspnet project and submit
contributions that will make the software run on Unix.
- Look into technologies like Owin and Katana (sp?) and help us
have a story that plugs into Unix HTTP servers (the equivalent of our
bridge between Apache and mono: mod_mono, or our Fast CGI bridge to
mono).
- Take Mono's new profiling tools and performance counters for a
spin and help us fine tune the runtime to run .NET code faster on
Unix than
you can on Windows. While this is a tall order, my friend David
Miller
would expect nothing less from us.
Hugs and love,
Miguel
Re: [Mono-dev] Mono and ASP.NET vNext
I think we should have something like Mono.Sockets with abstraction of
event loop and I/O code based on libuv or whatever, and build classes like
HttpListener on top of it.
2014-05-15 21:30 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
I suspect that having libuv behind socket code won't help much, since most
of socket performance problems are related to the fact that
BeginSend/Recieve, event loop and AsyncCallback run in different threads.
Because of that we have overhead even with simple
void ReadNext()
{
_socket.BeginRecieve(buf, blablabla, res=
{
_socket.EndRecieve(res);
ReadNext();
});
}
On windows that works fine because of IOCP behind that abstraction that is
designed to be used with thread pool. *nix platforms doesn't have anything
like IOCP, only epoll/kqueue, so for actual performance improvement one
have to use single-threaded approach (with round-robin connection dispatch
between workers), when all I/O operations and event loop run in single
thread.
2014-05-15 20:55 GMT+04:00 Miguel de Icaza mig...@xamarin.com:
Hello,
Well, i want to see a prototype, and then decide.
So this needs to be done with some kind of peer framework where this is
done.
On Thu, May 15, 2014 at 9:29 AM, Greg Young gregoryyou...@gmail.comwrote:
Yes I would say moving both to libuv would be a good move :)
On Thu, May 15, 2014 at 4:22 PM, Roope Kangas
ro...@grandcrugames.comwrote:
Hi,
On a tangent...
It would be really nice if something like libuv would the thing behind
Socket code.
Could that be something to investigate?
Mono could basically piggyback on nodejs development.
--
Roope Kangas
On 15.5.2014, at 15.00, Greg Young gregoryyou...@gmail.com wrote:
So the one issue I have seen with the libevent implementation is that
it seems to perform very poorly in windows (+-5k hello worlds/second where
as its closer to 100k/second in linux). From researching libevent they
supposedly now use IOCP in windows and should be better but I have not been
able to make this happen. It may also be worth looking at libuv which is
pretty close to a drop in replacement for libevent as it seems to get much
better performance in windows and similar performance in linux. @Nikita I
will hopefully have some time next week and likely will send some more pull
requests in relation to the memory allocation patterns.
On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza mig...@xamarin.comwrote:
Hello Nikita!
Your approach looks fabulous! I look forward to trying it out!
Miguel
On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov kek...@gmail.comwrote:
I'll try to implement OWIN host on top of my libevent built-in http
server ( https://github.com/kekekeks/evhttp-sharp ) since for now
it's the fastest thing for handling HTTP-requests on Mono I know (now it
has host implementation for NancyFx which we are using in production for
half of a year).
Although both evhttp-sharp and FastCGI servers like HyperFastCGI and
Fos, are incapable of serving websockets (one because of underlying
implementation, another because of limitations of FastCGI protocol), so
it
would be great to wrap something like
https://github.com/kekekeks/evhttp-sharp which has websocket support
and positioned as evhttp drop-in replacement.
Regards,
Nikita
2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
Wow! This is such great news!!
As for running Owin applications with Unix HTTP servers, I've
developed Fos http://github.com/mzabani/Fos on a very permissive
license and a focus on good documentation and running with Mono on
*nix. I
would very much love getting contributions on this, because my spare
time
is running lower these days.
Hope it helps,
Marcelo.
On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza
mig...@xamarin.com wrote:
Hello guys!
Microsoft has open sourced ASP.NET vNext:
http://github.com/aspnet/home
This is an entire new web stack that only needs the core of Mono
(does not even use System.Web.dll!).
So these are of course great news, because (a) The core Mono has
been in active development, and (b) that means that Mono's on the
server
can be used without all those pesky limitations that have been
plaguing us
for years.
So we ran into a couple of limitations in Mono: some classes that
they need are not implemented (I filed a bug, and a couple of Xamarin
folks
decided to take on that on their copious spare time) and we have a
couple
of bugs on FileSystemWatcher on OSX.
But this is a great time to:
- Get involved with the github.com/aspnet project and submit
contributions that will make the software run on Unix.
- Look into technologies like Owin and Katana (sp?) and help us
have a story that plugs into Unix HTTP servers (the equivalent of
our
bridge between Apache and mono: mod_mono, or our Fast CGI bridge to
mono).
- Take Mono's new profiling tools and performance counters
Re: [Mono-dev] Mono and ASP.NET vNext
There are some existing wrappers:
https://github.com/kersny/libuv-csharp - Dead, no commits for 3 years
https://github.com/txdv/LibuvSharp - uses Task (
https://github.com/txdv/LibuvSharp/blob/master/Examples/TcpAsync.cs ), so
it should have same problems with thread pool
2014-05-15 21:41 GMT+04:00 Greg Young gregoryyou...@gmail.com:
That would make sense as the models are different. Also that libuv wrapper
from looking looks fairly promising.
On Thu, May 15, 2014 at 8:38 PM, Nikita Tsukanov kek...@gmail.com wrote:
I think we should have something like Mono.Sockets with abstraction of
event loop and I/O code based on libuv or whatever, and build classes like
HttpListener on top of it.
2014-05-15 21:30 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
I suspect that having libuv behind socket code won't help much, since
most of socket performance problems are related to the fact that
BeginSend/Recieve, event loop and AsyncCallback run in different threads.
Because of that we have overhead even with simple
void ReadNext()
{
_socket.BeginRecieve(buf, blablabla, res=
{
_socket.EndRecieve(res);
ReadNext();
});
}
On windows that works fine because of IOCP behind that abstraction that
is designed to be used with thread pool. *nix platforms doesn't have
anything like IOCP, only epoll/kqueue, so for actual performance
improvement one have to use single-threaded approach (with round-robin
connection dispatch between workers), when all I/O operations and event
loop run in single thread.
2014-05-15 20:55 GMT+04:00 Miguel de Icaza mig...@xamarin.com:
Hello,
Well, i want to see a prototype, and then decide.
So this needs to be done with some kind of peer framework where this is
done.
On Thu, May 15, 2014 at 9:29 AM, Greg Young gregoryyou...@gmail.comwrote:
Yes I would say moving both to libuv would be a good move :)
On Thu, May 15, 2014 at 4:22 PM, Roope Kangas ro...@grandcrugames.com
wrote:
Hi,
On a tangent...
It would be really nice if something like libuv would the thing
behind Socket code.
Could that be something to investigate?
Mono could basically piggyback on nodejs development.
--
Roope Kangas
On 15.5.2014, at 15.00, Greg Young gregoryyou...@gmail.com wrote:
So the one issue I have seen with the libevent implementation is that
it seems to perform very poorly in windows (+-5k hello worlds/second
where
as its closer to 100k/second in linux). From researching libevent they
supposedly now use IOCP in windows and should be better but I have not
been
able to make this happen. It may also be worth looking at libuv which is
pretty close to a drop in replacement for libevent as it seems to get
much
better performance in windows and similar performance in linux. @Nikita I
will hopefully have some time next week and likely will send some more
pull
requests in relation to the memory allocation patterns.
On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza
mig...@xamarin.comwrote:
Hello Nikita!
Your approach looks fabulous! I look forward to trying it out!
Miguel
On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov
kek...@gmail.comwrote:
I'll try to implement OWIN host on top of my libevent built-in http
server ( https://github.com/kekekeks/evhttp-sharp ) since for now
it's the fastest thing for handling HTTP-requests on Mono I know (now
it
has host implementation for NancyFx which we are using in production
for
half of a year).
Although both evhttp-sharp and FastCGI servers like HyperFastCGI
and Fos, are incapable of serving websockets (one because of underlying
implementation, another because of limitations of FastCGI protocol),
so it
would be great to wrap something like
https://github.com/kekekeks/evhttp-sharp which has websocket
support and positioned as evhttp drop-in replacement.
Regards,
Nikita
2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
Wow! This is such great news!!
As for running Owin applications with Unix HTTP servers, I've
developed Fos http://github.com/mzabani/Fos on a very
permissive license and a focus on good documentation and running with
Mono
on *nix. I would very much love getting contributions on this,
because my
spare time is running lower these days.
Hope it helps,
Marcelo.
On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza
mig...@xamarin.com wrote:
Hello guys!
Microsoft has open sourced ASP.NET vNext:
http://github.com/aspnet/home
This is an entire new web stack that only needs the core of Mono
(does not even use System.Web.dll!).
So these are of course great news, because (a) The core Mono has
been in active development, and (b) that means that Mono's on the
server
can be used without all those pesky limitations that have been
plaguing us
for years.
So we ran into a couple of limitations in Mono: some classes that
they need are not implemented (I filed a bug, and a couple of
Xamarin folks
decided
Re: [Mono-dev] Mono and ASP.NET vNext
Now I'm digging the source code and it seems that second one is quite close
to what is needed.
2014-05-15 21:51 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
There are some existing wrappers:
https://github.com/kersny/libuv-csharp - Dead, no commits for 3 years
https://github.com/txdv/LibuvSharp - uses Task (
https://github.com/txdv/LibuvSharp/blob/master/Examples/TcpAsync.cs ), so
it should have same problems with thread pool
2014-05-15 21:41 GMT+04:00 Greg Young gregoryyou...@gmail.com:
That would make sense as the models are different. Also that libuv wrapper
from looking looks fairly promising.
On Thu, May 15, 2014 at 8:38 PM, Nikita Tsukanov kek...@gmail.comwrote:
I think we should have something like Mono.Sockets with abstraction of
event loop and I/O code based on libuv or whatever, and build classes like
HttpListener on top of it.
2014-05-15 21:30 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
I suspect that having libuv behind socket code won't help much, since
most of socket performance problems are related to the fact that
BeginSend/Recieve, event loop and AsyncCallback run in different threads.
Because of that we have overhead even with simple
void ReadNext()
{
_socket.BeginRecieve(buf, blablabla, res=
{
_socket.EndRecieve(res);
ReadNext();
});
}
On windows that works fine because of IOCP behind that abstraction that
is designed to be used with thread pool. *nix platforms doesn't have
anything like IOCP, only epoll/kqueue, so for actual performance
improvement one have to use single-threaded approach (with round-robin
connection dispatch between workers), when all I/O operations and event
loop run in single thread.
2014-05-15 20:55 GMT+04:00 Miguel de Icaza mig...@xamarin.com:
Hello,
Well, i want to see a prototype, and then decide.
So this needs to be done with some kind of peer framework where this
is done.
On Thu, May 15, 2014 at 9:29 AM, Greg Young
gregoryyou...@gmail.comwrote:
Yes I would say moving both to libuv would be a good move :)
On Thu, May 15, 2014 at 4:22 PM, Roope Kangas
ro...@grandcrugames.com wrote:
Hi,
On a tangent...
It would be really nice if something like libuv would the thing
behind Socket code.
Could that be something to investigate?
Mono could basically piggyback on nodejs development.
--
Roope Kangas
On 15.5.2014, at 15.00, Greg Young gregoryyou...@gmail.com wrote:
So the one issue I have seen with the libevent implementation is
that it seems to perform very poorly in windows (+-5k hello
worlds/second
where as its closer to 100k/second in linux). From researching libevent
they supposedly now use IOCP in windows and should be better but I have
not
been able to make this happen. It may also be worth looking at libuv
which
is pretty close to a drop in replacement for libevent as it seems to get
much better performance in windows and similar performance in linux.
@Nikita I will hopefully have some time next week and likely will send
some
more pull requests in relation to the memory allocation patterns.
On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza mig...@xamarin.com
wrote:
Hello Nikita!
Your approach looks fabulous! I look forward to trying it out!
Miguel
On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov kek...@gmail.com
wrote:
I'll try to implement OWIN host on top of my libevent built-in
http server ( https://github.com/kekekeks/evhttp-sharp ) since
for now it's the fastest thing for handling HTTP-requests on Mono I
know
(now it has host implementation for NancyFx which we are using in
production for half of a year).
Although both evhttp-sharp and FastCGI servers like HyperFastCGI
and Fos, are incapable of serving websockets (one because of
underlying
implementation, another because of limitations of FastCGI protocol),
so it
would be great to wrap something like
https://github.com/kekekeks/evhttp-sharp which has websocket
support and positioned as evhttp drop-in replacement.
Regards,
Nikita
2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
Wow! This is such great news!!
As for running Owin applications with Unix HTTP servers, I've
developed Fos http://github.com/mzabani/Fos on a very
permissive license and a focus on good documentation and running
with Mono
on *nix. I would very much love getting contributions on this,
because my
spare time is running lower these days.
Hope it helps,
Marcelo.
On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza
mig...@xamarin.com wrote:
Hello guys!
Microsoft has open sourced ASP.NET vNext:
http://github.com/aspnet/home
This is an entire new web stack that only needs the core of Mono
(does not even use System.Web.dll!).
So these are of course great news, because (a) The core Mono has
been in active development, and (b) that means that Mono's on the
server
can be used without all those pesky limitations that have been
plaguing us
Re: [Mono-dev] Mono and ASP.NET vNext
The main problem that someone have to implement HTTP-server and
websocket-handling code on top of that, since existing implementations
(Nowin, websocket implementations on top of XSockets, SuperSockets.NET,
etc) are bound to thread pool model. I think it's much better to find some
existing HTTP/WebSocket server library, wrap it and use for hosting
ASP.NETvNext applications. It will safe a lot of pain. Althrough it's
possible to
patch something like Nowin in a way, that it would be able to use both
models and switch between them.
2014-05-15 21:59 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
Now I'm digging the source code and it seems that second one is quite
close to what is needed.
2014-05-15 21:51 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
There are some existing wrappers:
https://github.com/kersny/libuv-csharp - Dead, no commits for 3 years
https://github.com/txdv/LibuvSharp - uses Task (
https://github.com/txdv/LibuvSharp/blob/master/Examples/TcpAsync.cs ),
so it should have same problems with thread pool
2014-05-15 21:41 GMT+04:00 Greg Young gregoryyou...@gmail.com:
That would make sense as the models are different. Also that libuv
wrapper from looking looks fairly promising.
On Thu, May 15, 2014 at 8:38 PM, Nikita Tsukanov kek...@gmail.comwrote:
I think we should have something like Mono.Sockets with abstraction of
event loop and I/O code based on libuv or whatever, and build classes like
HttpListener on top of it.
2014-05-15 21:30 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
I suspect that having libuv behind socket code won't help much, since
most of socket performance problems are related to the fact that
BeginSend/Recieve, event loop and AsyncCallback run in different threads.
Because of that we have overhead even with simple
void ReadNext()
{
_socket.BeginRecieve(buf, blablabla, res=
{
_socket.EndRecieve(res);
ReadNext();
});
}
On windows that works fine because of IOCP behind that abstraction
that is designed to be used with thread pool. *nix platforms doesn't have
anything like IOCP, only epoll/kqueue, so for actual performance
improvement one have to use single-threaded approach (with round-robin
connection dispatch between workers), when all I/O operations and event
loop run in single thread.
2014-05-15 20:55 GMT+04:00 Miguel de Icaza mig...@xamarin.com:
Hello,
Well, i want to see a prototype, and then decide.
So this needs to be done with some kind of peer framework where this
is done.
On Thu, May 15, 2014 at 9:29 AM, Greg Young
gregoryyou...@gmail.comwrote:
Yes I would say moving both to libuv would be a good move :)
On Thu, May 15, 2014 at 4:22 PM, Roope Kangas
ro...@grandcrugames.com wrote:
Hi,
On a tangent...
It would be really nice if something like libuv would the thing
behind Socket code.
Could that be something to investigate?
Mono could basically piggyback on nodejs development.
--
Roope Kangas
On 15.5.2014, at 15.00, Greg Young gregoryyou...@gmail.com wrote:
So the one issue I have seen with the libevent implementation is
that it seems to perform very poorly in windows (+-5k hello
worlds/second
where as its closer to 100k/second in linux). From researching libevent
they supposedly now use IOCP in windows and should be better but I
have not
been able to make this happen. It may also be worth looking at libuv
which
is pretty close to a drop in replacement for libevent as it seems to
get
much better performance in windows and similar performance in linux.
@Nikita I will hopefully have some time next week and likely will send
some
more pull requests in relation to the memory allocation patterns.
On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza
mig...@xamarin.com wrote:
Hello Nikita!
Your approach looks fabulous! I look forward to trying it out!
Miguel
On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov
kek...@gmail.com wrote:
I'll try to implement OWIN host on top of my libevent built-in
http server ( https://github.com/kekekeks/evhttp-sharp ) since
for now it's the fastest thing for handling HTTP-requests on Mono I
know
(now it has host implementation for NancyFx which we are using in
production for half of a year).
Although both evhttp-sharp and FastCGI servers like HyperFastCGI
and Fos, are incapable of serving websockets (one because of
underlying
implementation, another because of limitations of FastCGI protocol),
so it
would be great to wrap something like
https://github.com/kekekeks/evhttp-sharp which has websocket
support and positioned as evhttp drop-in replacement.
Regards,
Nikita
2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
Wow! This is such great news!!
As for running Owin applications with Unix HTTP servers, I've
developed Fos http://github.com/mzabani/Fos on a very
permissive license and a focus on good documentation and running
with Mono
on *nix. I would very much love
Re: [Mono-dev] Mono and ASP.NET vNext
I'll try to implement OWIN host on top of my libevent built-in http server ( https://github.com/kekekeks/evhttp-sharp ) since for now it's the fastest thing for handling HTTP-requests on Mono I know (now it has host implementation for NancyFx which we are using in production for half of a year). Although both evhttp-sharp and FastCGI servers like HyperFastCGI and Fos, are incapable of serving websockets (one because of underlying implementation, another because of limitations of FastCGI protocol), so it would be great to wrap something like https://github.com/kekekeks/evhttp-sharp which has websocket support and positioned as evhttp drop-in replacement. Regards, Nikita 2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com: Wow! This is such great news!! As for running Owin applications with Unix HTTP servers, I've developed Fos http://github.com/mzabani/Fos on a very permissive license and a focus on good documentation and running with Mono on *nix. I would very much love getting contributions on this, because my spare time is running lower these days. Hope it helps, Marcelo. On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza mig...@xamarin.comwrote: Hello guys! Microsoft has open sourced ASP.NET vNext: http://github.com/aspnet/home This is an entire new web stack that only needs the core of Mono (does not even use System.Web.dll!). So these are of course great news, because (a) The core Mono has been in active development, and (b) that means that Mono's on the server can be used without all those pesky limitations that have been plaguing us for years. So we ran into a couple of limitations in Mono: some classes that they need are not implemented (I filed a bug, and a couple of Xamarin folks decided to take on that on their copious spare time) and we have a couple of bugs on FileSystemWatcher on OSX. But this is a great time to: - Get involved with the github.com/aspnet project and submit contributions that will make the software run on Unix. - Look into technologies like Owin and Katana (sp?) and help us have a story that plugs into Unix HTTP servers (the equivalent of our bridge between Apache and mono: mod_mono, or our Fast CGI bridge to mono). - Take Mono's new profiling tools and performance counters for a spin and help us fine tune the runtime to run .NET code faster on Unix than you can on Windows. While this is a tall order, my friend David Miller would expect nothing less from us. Hugs and love, Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and ASP.NET vNext
s/built-in http server/built-in http server wrapper/ 2014-05-14 19:40 GMT+04:00 Nikita Tsukanov kek...@gmail.com: I'll try to implement OWIN host on top of my libevent built-in http server ( https://github.com/kekekeks/evhttp-sharp ) since for now it's the fastest thing for handling HTTP-requests on Mono I know (now it has host implementation for NancyFx which we are using in production for half of a year). Although both evhttp-sharp and FastCGI servers like HyperFastCGI and Fos, are incapable of serving websockets (one because of underlying implementation, another because of limitations of FastCGI protocol), so it would be great to wrap something like https://github.com/kekekeks/evhttp-sharp which has websocket support and positioned as evhttp drop-in replacement. Regards, Nikita 2014-05-14 19:29 GMT+04:00 Marcelo Zabani mzab...@gmail.com: Wow! This is such great news!! As for running Owin applications with Unix HTTP servers, I've developed Fos http://github.com/mzabani/Fos on a very permissive license and a focus on good documentation and running with Mono on *nix. I would very much love getting contributions on this, because my spare time is running lower these days. Hope it helps, Marcelo. On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza mig...@xamarin.comwrote: Hello guys! Microsoft has open sourced ASP.NET vNext: http://github.com/aspnet/home This is an entire new web stack that only needs the core of Mono (does not even use System.Web.dll!). So these are of course great news, because (a) The core Mono has been in active development, and (b) that means that Mono's on the server can be used without all those pesky limitations that have been plaguing us for years. So we ran into a couple of limitations in Mono: some classes that they need are not implemented (I filed a bug, and a couple of Xamarin folks decided to take on that on their copious spare time) and we have a couple of bugs on FileSystemWatcher on OSX. But this is a great time to: - Get involved with the github.com/aspnet project and submit contributions that will make the software run on Unix. - Look into technologies like Owin and Katana (sp?) and help us have a story that plugs into Unix HTTP servers (the equivalent of our bridge between Apache and mono: mod_mono, or our Fast CGI bridge to mono). - Take Mono's new profiling tools and performance counters for a spin and help us fine tune the runtime to run .NET code faster on Unix than you can on Windows. While this is a tall order, my friend David Miller would expect nothing less from us. Hugs and love, Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FastCGI Performance
Hello there. Today I spent some time messing up with libevent and managed to implement multiworker mode (multiple threads accepting connections from the same socket) in my evhttp-sharp wrapper. That gave me 2.5 times faster results in benchmark (from 32K to 79K rps). Now I'll send pull request to FrameworkBenchmarks guys. Regards, Nikita Tsukanov 2014-04-09 23:51 GMT+04:00 xplicit s...@ngs.ru: I like this. If it provides the ability to easy change one listener to other and also ability to change HTTP servers it'll be awesome. By the way it also should provide the ability to run current ASP.NET server otherwise people could not migrate their web application to Linux platform. ASP.NETrequires some additional things to startup, like create AppDomain with appropriate security evidence for every web application, route requests to correct AppDomain according to virtual path and so on. These produce additional level of complexity, which possible does not required by raw HTTP servers, but I think it can be simplified. If you guys are intrested in this, I can share some ideas and tell about issues and constraints I met when I tried to integrate ASP.NET with nginx. -- View this message in context: http://mono.1490590.n4.nabble.com/FastCGI-Performance-tp4662454p4662500.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FastCGI Performance
Oh, sorry for misinformation. FrameworkBenchmarks already has experimental and buggy implementation of the same thing (see multiworker branch). So the good news that it can be now considered stable. Profiling with some optimizations gave me about 20% performance boost however. Before: Running 25s test @ http://127.0.0.1:8083/ 10 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 6.38ms5.51ms 59.43ms 79.82% Req/Sec10.80k 3.90k 29.20k66.14% 2469415 requests in 24.99s, 329.70MB read Requests/sec: 98803.25 Transfer/sec: 13.19MB After: Running 25s test @ http://127.0.0.1:8083/ 10 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 8.06ms 12.65ms 81.59ms 90.45% Req/Sec12.36k 4.94k 26.73k71.89% 2983443 requests in 24.99s, 398.33MB read Requests/sec: 119391.93 Transfer/sec: 15.94MB Regards, Nikita 2014-04-12 21:11 GMT+04:00 Nikita Tsukanov kek...@gmail.com: Oh, sorry for misinformation. FrameworkBenchmarks already has experimental and buggy implementation of the same thing (see multiworker branch). So the good news that it can be now considered stable. Regards, Nikita Tsukanov 2014-04-12 20:53 GMT+04:00 Greg Young gregoryyou...@gmail.com: Nice I will pull and check it out. Good work. Greg On Sat, Apr 12, 2014 at 7:50 PM, Nikita Tsukanov kek...@gmail.comwrote: Hello there. Today I spent some time messing up with libevent and managed to implement multiworker mode (multiple threads accepting connections from the same socket) in my evhttp-sharp wrapper. That gave me 2.5 times faster results in benchmark (from 32K to 79K rps). Now I'll send pull request to FrameworkBenchmarks guys. Regards, Nikita Tsukanov 2014-04-09 23:51 GMT+04:00 xplicit s...@ngs.ru: I like this. If it provides the ability to easy change one listener to other and also ability to change HTTP servers it'll be awesome. By the way it also should provide the ability to run current ASP.NET server otherwise people could not migrate their web application to Linux platform. ASP.NETrequires some additional things to startup, like create AppDomain with appropriate security evidence for every web application, route requests to correct AppDomain according to virtual path and so on. These produce additional level of complexity, which possible does not required by raw HTTP servers, but I think it can be simplified. If you guys are intrested in this, I can share some ideas and tell about issues and constraints I met when I tried to integrate ASP.NET with nginx. -- View this message in context: http://mono.1490590.n4.nabble.com/FastCGI-Performance-tp4662454p4662500.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FastCGI Performance
It would be great to create some transport-independent ASP.NET host that
can be easily integrated with any raw HTTP server. I tried to dig in the
code of default Mono implementation several months ago, but quickly gave up.
That host should ask the user for IHttpServer implementation with
IHttpServer defined like this:
interface IHttpServer
{
event ActionIHttpRequest OnRequest;
}
interface IHttpRequest
{
string Method {get;}
string PathAndQuery {get;}
//blablabla
void Respond (int code, byte[] payload, IDictionarystring, string
headers);
}
2014-04-09 1:01 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
xplicit, perhaps we could concentrate the effort of the FastCgi parts in
HyperFastCgi in a separate library? I think both our projects and the
community could benefit from this. I'm not sure how developed the FastCgi
parts in HyperFastCgi are, but perhaps we could merge the good of both into
FastCgiNet? (http://github.com/mzabani/FastCgiNet).
At this point FastCgiNet is reasonably well documented (its code as well)
- the best docs I've seen in any FastCgi library for .NET - so it shouldn't
be *too* hard for other people to help.
On Tue, Apr 8, 2014 at 4:33 PM, etienne.champet...@free.fr wrote:
Hi
This thread is named FastCGI performance, but much more important than
performance is stablility, ie don't explode (10Gb memory usage :)).
I want to thanks Sergey for his HyperFastCGI, because it seems to handle
load just fine (ab -c200)(response time goes up, thread number stay at
~35,
and memory is between 90Mb and 200Mb)
- Mail original -
De: Sergey Zhukov s...@ngs.ru
À: Giuliano Barberi gbarb...@aotaonline.com
Cc: Mono Developer List mono-devel-list@lists.ximian.com
Envoyé: Mardi 8 Avril 2014 20:50:23
Objet: Re: [Mono-dev] FastCGI Performance
To be more exact I did not write some special code for connection
pooling, but I did thread pooling for MonoWorkerRequest and tried to
pool CGI records, which are used for communication between nginx and
FastCgi server. The last one did not show any increasing in
performance
for me, and I did not merge the code to master branch. The second one
can be enabled or disabled with /usethreadpool=yes|no option.
About connection pooling: KeepAlive mode reuses opened connections
very
good, so for 10 tests requests I get only 50-60 instances of
NetworkConnector are created. You can check it by adding the line
if (cn % 10 == 0)
Logger.Write (LogLevel.All, cn={0}, cn);
to the end of NetworkConnector constructor. If you see that cn is
growing, that something wrong with configuration and this produces
huge
drop of performance.
Also, I'll look into benchmarks you point out and will see, what can
be
done more to increase performance.
On Tue, 2014-04-08 at 13:19 -0400, Giuliano Barberi wrote:
I'm gonna close this issue. I mainly opened it to ask about whether
that would help a lot but I can see from you said it won't since
you're already pooling. The evhttp-sharp implementation does use
native calls though it uses evhttp from libevent but the author
says
the main bottleneck at this point is that its single threaded in
case
you want something to compare against.
Regards
On Tue, Apr 8, 2014 at 12:03 PM, xplicit s...@ngs.ru wrote:
From my point of view the bollteneck currently is not in
the
socket library,
but in the System.Web implementation. For example, when I
did
benchmarks for
HyperFastCgi server, I've got such results:
Get static file from nginx - 10K rps
Get hardcoded html-response from HyperFastCgi server
(without
passing http
request to mono web.server) - ~5K rps.
Yes, it's double-time drop in performance, but I think
that's
mostly because
static file is cached inside nginx, while using fastcgi
requires additional
layer of communication throught sockets.
Then when I added mono web server to the nginx-fastcgi
chain
performance
dropped to 1.5-2K rps depending on the requests were
served.
I'm pretty
sure, if you remove all sockets references from web server
and
will emulate
HTTP requests directly to System.Web you won't get
incredible
improvement of
performance, it will still be slow. However, I might be
wrong,
all
performance assumptions must be measured, because sometimes
you'll get
results is not what you expect.
But what I saw:
System.Web uses very slow implementation of
System.Configuration. For every
request path not in cache it tries to find
Re: [Mono-dev] FastCGI Performance
It's also worth not to invent that IHttpServer mechanism from scratch, but
just use existing OWIN standard ( http://owin.org/ ).
Regards,
Nikita
2014-04-09 4:27 GMT+04:00 Nikita Tsukanov kek...@gmail.com:
It would be great to create some transport-independent ASP.NET host that
can be easily integrated with any raw HTTP server. I tried to dig in the
code of default Mono implementation several months ago, but quickly gave up.
That host should ask the user for IHttpServer implementation with
IHttpServer defined like this:
interface IHttpServer
{
event ActionIHttpRequest OnRequest;
}
interface IHttpRequest
{
string Method {get;}
string PathAndQuery {get;}
//blablabla
void Respond (int code, byte[] payload, IDictionarystring, string
headers);
}
2014-04-09 1:01 GMT+04:00 Marcelo Zabani mzab...@gmail.com:
xplicit, perhaps we could concentrate the effort of the FastCgi parts in
HyperFastCgi in a separate library? I think both our projects and the
community could benefit from this. I'm not sure how developed the FastCgi
parts in HyperFastCgi are, but perhaps we could merge the good of both into
FastCgiNet? (http://github.com/mzabani/FastCgiNet).
At this point FastCgiNet is reasonably well documented (its code as well)
- the best docs I've seen in any FastCgi library for .NET - so it shouldn't
be *too* hard for other people to help.
On Tue, Apr 8, 2014 at 4:33 PM, etienne.champet...@free.fr wrote:
Hi
This thread is named FastCGI performance, but much more important than
performance is stablility, ie don't explode (10Gb memory usage :)).
I want to thanks Sergey for his HyperFastCGI, because it seems to handle
load just fine (ab -c200)(response time goes up, thread number stay at
~35,
and memory is between 90Mb and 200Mb)
- Mail original -
De: Sergey Zhukov s...@ngs.ru
À: Giuliano Barberi gbarb...@aotaonline.com
Cc: Mono Developer List mono-devel-list@lists.ximian.com
Envoyé: Mardi 8 Avril 2014 20:50:23
Objet: Re: [Mono-dev] FastCGI Performance
To be more exact I did not write some special code for connection
pooling, but I did thread pooling for MonoWorkerRequest and tried to
pool CGI records, which are used for communication between nginx and
FastCgi server. The last one did not show any increasing in
performance
for me, and I did not merge the code to master branch. The second one
can be enabled or disabled with /usethreadpool=yes|no option.
About connection pooling: KeepAlive mode reuses opened connections
very
good, so for 10 tests requests I get only 50-60 instances of
NetworkConnector are created. You can check it by adding the line
if (cn % 10 == 0)
Logger.Write (LogLevel.All, cn={0}, cn);
to the end of NetworkConnector constructor. If you see that cn is
growing, that something wrong with configuration and this produces
huge
drop of performance.
Also, I'll look into benchmarks you point out and will see, what can
be
done more to increase performance.
On Tue, 2014-04-08 at 13:19 -0400, Giuliano Barberi wrote:
I'm gonna close this issue. I mainly opened it to ask about whether
that would help a lot but I can see from you said it won't since
you're already pooling. The evhttp-sharp implementation does use
native calls though it uses evhttp from libevent but the author
says
the main bottleneck at this point is that its single threaded in
case
you want something to compare against.
Regards
On Tue, Apr 8, 2014 at 12:03 PM, xplicit s...@ngs.ru wrote:
From my point of view the bollteneck currently is not in
the
socket library,
but in the System.Web implementation. For example, when I
did
benchmarks for
HyperFastCgi server, I've got such results:
Get static file from nginx - 10K rps
Get hardcoded html-response from HyperFastCgi server
(without
passing http
request to mono web.server) - ~5K rps.
Yes, it's double-time drop in performance, but I think
that's
mostly because
static file is cached inside nginx, while using fastcgi
requires additional
layer of communication throught sockets.
Then when I added mono web server to the nginx-fastcgi
chain
performance
dropped to 1.5-2K rps depending on the requests were
served.
I'm pretty
sure, if you remove all sockets references from web server
and
will emulate
HTTP requests directly to System.Web you won't get
incredible
improvement of
performance, it will still be slow. However, I might be
wrong,
all
performance assumptions must be measured, because sometimes
you'll get
Re: [Mono-dev] FastCGI Performance
Author of that libevent-wrapper reporting in. It seems that the implementation of asynchronous sockets in Mono is limited to the original Win32 API model with I/O completion ports, (i. e. multiple threads from a thread pool waiting for some events from sockets, done at Windows kernel level). On Linux/MacOS Mono has to emulate that by running a separate thread for epoll/kqueue event loop and then queueing callbacks passed to BeginRead/Write to a common thread pool. This approach will always cause some thread-communication overhead, so it's almost impossible to create an efficient socket server implementation using System.Net.Sockets. It might be worth to create some single-threaded socket I/O stack using libuv and async/await model with custom synchronization context (actual ReadAsync and WriteAsync don't even need to return Task, just something that has GetAwaiter method). Regards, Nikita 2014-04-07 19:52 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: I think just running the same test as evhttp-listener in the TechemPower Benchmark where it serializes JSON is fine. All we are looking for is a comparison. If we submit the test to them on Github then it should be available for the next benchmark too. Seems like we could add the HyperFastCgi and the FOS implementations. So far the evhttp one is super fast but it relies on native code so it has some custom code to pick either the Windows DLL or the Linux SO and needs those dependencies installed separately. It would be great to have a fast C# implementation. Regards On Apr 7, 2014 10:20 AM, Marcelo Zabani mzab...@gmail.com wrote: I have not compared the fastcgi implementation per se, because it is not very easy to test only the underlying fastcgi implementations and I never had the time for that. Fos, however, is a highly asynchronous server implementation, and I've seen it dealing with a lot of connections simultaneously. I haven't benchmarked it properly and compared it to other servers yet, but I'll try to do that in the next two weeks. I run a website with Fos and I get 10-20ms average response time (measured as Fos - Nginx, that is, not counting the time it takes for the response to reach the user) with static pages. In case you want to take a better look at these numbers, take a look at http://beeder.com.br/_stats Don't be scared by the large response times for some of the URLs, as those are usually contacting Facebook through Fb's API. On Mon, Apr 7, 2014 at 8:02 AM, Giuliano Barberi gbarb...@aotaonline.com wrote: Have you benchmarked it to see how it compares to the existing FastCGI implementation? Regards On Sun, Apr 6, 2014 at 11:03 PM, Marcelo Zabani mzab...@gmail.comwrote: In case you want to host an OWIN application with Mono and FastCgi, you may wanna take a look at a project of mine, Fos: https://github.com/mzabani/Fos It is also available at NuGet. -- From: Greg Najda gregna...@gmail.com Sent: 06/04/2014 22:43 To: Giuliano Barberi gbarb...@aotaonline.com Cc: Mono Developer List mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] FastCGI Performance Someone looked into Mono FastCGI performance a couple months ago and made a series of blog posts: http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p1.html http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p2.html http://forcedtoadmin.blogspot.com/2013/12/servicestack-performance-in-mono-p3.html He ended up writing a replacement for the Mono FastCGI server instead of changing it because of architectural changes: https://github.com/xplicit/HyperFastCgi On Sun, Apr 6, 2014 at 7:43 PM, Giuliano Barberi gbarb...@aotaonline.com wrote: After looking at some of the Mono web benchmarks ( http://www.techempower.com/benchmarks/#section=data-r8hw=i7test=jsons=2p=13ydj4-0 ) I got very curious as to why FastCGI performance was so much lower than when using a C# libevent implementation. If you look at nancy-libevent2 vs nancy benchmarks, the only difference is a C# wrapper around libevent ( https://github.com/kekekeks/evhttp-sharp ) vs Mono FastCGI. Since Mono uses epoll underneath which is what libevent uses afaik, I would not expect there to be such a gap in performance. I'm curious whether performance of FastCGI is being looked at or if this is expected. Mono when using FastCGI benchmarks almost at the bottom of the list when compared to many other technologies ( http://www.techempower.com/benchmarks/#section=data-r8hw=i7test=json ). I've done a bit of analysis on where the bottleneck is and everything I've found is pointing to the FastCGI implementation. Regards -- Giuliano Barberi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Giuliano Barberi
Re: [Mono-dev] FastCGI Performance
You shouldn't worry much about plain-HTTP vs. FastCGI, since HTTP/1.1 has that wonderful connection keep-alive feature well supported by nginx, and FastCGI's request multiplexing is very rarely supported by proxying-web servers (nginx doesn't have support for that, for example). The main bottleneck of evhttp is the fact that it's able to utilize only one CPU core per listened socket (main event loop is single-threaded). I. e. it's impossible to accept connection on one evbase and pass that socket to evhttp on another. So the lack of worker thread concept for I/O limits benchmark value to 90K rps. With some trivial patches for libevent2 it will be possible to reach 300-350K rps on the same hardware. But in that case we have to ship patched version of libevent with the library itself. Regards, Nikita 2014-04-08 1:04 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: Nikita, thanks for your work on evhttp-sharp. I have looked into the Mono source and saw that too about how Mono just has an IO threadpool to complete the requests. I wonder if the overhead it adds is very large though or if it's still possible to make it efficient enough. The only thing that I don't like about the evhttp-sharp implementation is that we have to proxy the requests from the webserver to evhttp. A libuv solution would be interesting as well and could be implemented as a FastCGI wrapper instead of proxying the requests manually. There are already some wrappers around libuv for C# like https://github.com/txdv/LibuvSharp so it might not be hard to do the rest. Granted the evhttp-sharp performance is already great and this would only be worth it if it improves performance at the end of the day. On Mon, Apr 7, 2014 at 4:38 PM, Nikita Tsukanov kek...@gmail.com wrote: Author of that libevent-wrapper reporting in. It seems that the implementation of asynchronous sockets in Mono is limited to the original Win32 API model with I/O completion ports, (i. e. multiple threads from a thread pool waiting for some events from sockets, done at Windows kernel level). On Linux/MacOS Mono has to emulate that by running a separate thread for epoll/kqueue event loop and then queueing callbacks passed to BeginRead/Write to a common thread pool. This approach will always cause some thread-communication overhead, so it's almost impossible to create an efficient socket server implementation using System.Net.Sockets. It might be worth to create some single-threaded socket I/O stack using libuv and async/await model with custom synchronization context (actual ReadAsync and WriteAsync don't even need to return Task, just something that has GetAwaiter method). Regards, Nikita 2014-04-07 19:52 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: I think just running the same test as evhttp-listener in the TechemPower Benchmark where it serializes JSON is fine. All we are looking for is a comparison. If we submit the test to them on Github then it should be available for the next benchmark too. Seems like we could add the HyperFastCgi and the FOS implementations. So far the evhttp one is super fast but it relies on native code so it has some custom code to pick either the Windows DLL or the Linux SO and needs those dependencies installed separately. It would be great to have a fast C# implementation. Regards On Apr 7, 2014 10:20 AM, Marcelo Zabani mzab...@gmail.com wrote: I have not compared the fastcgi implementation per se, because it is not very easy to test only the underlying fastcgi implementations and I never had the time for that. Fos, however, is a highly asynchronous server implementation, and I've seen it dealing with a lot of connections simultaneously. I haven't benchmarked it properly and compared it to other servers yet, but I'll try to do that in the next two weeks. I run a website with Fos and I get 10-20ms average response time (measured as Fos - Nginx, that is, not counting the time it takes for the response to reach the user) with static pages. In case you want to take a better look at these numbers, take a look at http://beeder.com.br/_stats Don't be scared by the large response times for some of the URLs, as those are usually contacting Facebook through Fb's API. On Mon, Apr 7, 2014 at 8:02 AM, Giuliano Barberi gbarb...@aotaonline.com wrote: Have you benchmarked it to see how it compares to the existing FastCGI implementation? Regards On Sun, Apr 6, 2014 at 11:03 PM, Marcelo Zabani mzab...@gmail.comwrote: In case you want to host an OWIN application with Mono and FastCgi, you may wanna take a look at a project of mine, Fos: https://github.com/mzabani/Fos It is also available at NuGet. -- From: Greg Najda gregna...@gmail.com Sent: 06/04/2014 22:43 To: Giuliano Barberi gbarb...@aotaonline.com Cc: Mono Developer List mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] FastCGI Performance Someone looked into Mono
Re: [Mono-dev] FastCGI Performance
libuv itself doesn't have its own HTTP-server implementation, but if you want to create a general-purpose network I/O stack it's better to use libuv, since it's capable of using I/O completion ports on Windows (libevent uses select() which is good only for debugging). AFAIK, libuv was initially created for such stack of nodejs. Regards, Nikita 2014-04-08 1:34 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: Is that why you mention libuv? Does it not have the same issue as libevent in that regard? On Mon, Apr 7, 2014 at 5:29 PM, Nikita Tsukanov kek...@gmail.com wrote: You shouldn't worry much about plain-HTTP vs. FastCGI, since HTTP/1.1 has that wonderful connection keep-alive feature well supported by nginx, and FastCGI's request multiplexing is very rarely supported by proxying-web servers (nginx doesn't have support for that, for example). The main bottleneck of evhttp is the fact that it's able to utilize only one CPU core per listened socket (main event loop is single-threaded). I. e. it's impossible to accept connection on one evbase and pass that socket to evhttp on another. So the lack of worker thread concept for I/O limits benchmark value to 90K rps. With some trivial patches for libevent2 it will be possible to reach 300-350K rps on the same hardware. But in that case we have to ship patched version of libevent with the library itself. Regards, Nikita 2014-04-08 1:04 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: Nikita, thanks for your work on evhttp-sharp. I have looked into the Mono source and saw that too about how Mono just has an IO threadpool to complete the requests. I wonder if the overhead it adds is very large though or if it's still possible to make it efficient enough. The only thing that I don't like about the evhttp-sharp implementation is that we have to proxy the requests from the webserver to evhttp. A libuv solution would be interesting as well and could be implemented as a FastCGI wrapper instead of proxying the requests manually. There are already some wrappers around libuv for C# like https://github.com/txdv/LibuvSharp so it might not be hard to do the rest. Granted the evhttp-sharp performance is already great and this would only be worth it if it improves performance at the end of the day. On Mon, Apr 7, 2014 at 4:38 PM, Nikita Tsukanov kek...@gmail.comwrote: Author of that libevent-wrapper reporting in. It seems that the implementation of asynchronous sockets in Mono is limited to the original Win32 API model with I/O completion ports, (i. e. multiple threads from a thread pool waiting for some events from sockets, done at Windows kernel level). On Linux/MacOS Mono has to emulate that by running a separate thread for epoll/kqueue event loop and then queueing callbacks passed to BeginRead/Write to a common thread pool. This approach will always cause some thread-communication overhead, so it's almost impossible to create an efficient socket server implementation using System.Net.Sockets. It might be worth to create some single-threaded socket I/O stack using libuv and async/await model with custom synchronization context (actual ReadAsync and WriteAsync don't even need to return Task, just something that has GetAwaiter method). Regards, Nikita 2014-04-07 19:52 GMT+04:00 Giuliano Barberi gbarb...@aotaonline.com: I think just running the same test as evhttp-listener in the TechemPower Benchmark where it serializes JSON is fine. All we are looking for is a comparison. If we submit the test to them on Github then it should be available for the next benchmark too. Seems like we could add the HyperFastCgi and the FOS implementations. So far the evhttp one is super fast but it relies on native code so it has some custom code to pick either the Windows DLL or the Linux SO and needs those dependencies installed separately. It would be great to have a fast C# implementation. Regards On Apr 7, 2014 10:20 AM, Marcelo Zabani mzab...@gmail.com wrote: I have not compared the fastcgi implementation per se, because it is not very easy to test only the underlying fastcgi implementations and I never had the time for that. Fos, however, is a highly asynchronous server implementation, and I've seen it dealing with a lot of connections simultaneously. I haven't benchmarked it properly and compared it to other servers yet, but I'll try to do that in the next two weeks. I run a website with Fos and I get 10-20ms average response time (measured as Fos - Nginx, that is, not counting the time it takes for the response to reach the user) with static pages. In case you want to take a better look at these numbers, take a look at http://beeder.com.br/_stats Don't be scared by the large response times for some of the URLs, as those are usually contacting Facebook through Fb's API. On Mon, Apr 7, 2014 at 8:02 AM, Giuliano Barberi gbarb...@aotaonline.com wrote: Have you benchmarked
Re: [Mono-dev] Using Mono C# compiler for dynamic compilation of scripts
http://msdn.microsoft.com/en-us/library/system.codedom.compiler.codedomprovider.compileassemblyfromsource%28v=vs.110%29.aspx- it's not 'in-memory', but it's well-documented and you can delete temp file after loading it's contents (if you use Assembly.Load (File.ReadAllBytes (path)) Mono won't try to access the file after loading it). Regards, Nikita 2014-02-14 15:58 GMT+04:00 Rafal Gwizdala rafal.gwizd...@gmail.com: Hi guys, Sorry if this question shows my complete ignorance, but I'm stuck and don't know where to go next. I'm trying to use Mono C# compiler api for dynamic compilation of code blocks. I was trying to use the Mono.CSharp.Evaluator class, but it's rather suitable for evaling expressions or compiling simple code snippets into methods, and I'd like to do few different things: - compile whole class definition from a source file into an in-memory assembly - dynamically create a class by inheriting from an abstract base class and implementing / overriding a single abstract method in it with script code The second case is particularly interesting to me. What i'd like to to is write the method body in the script file, and then convert it into a derived class during compilation, so the script would not contain all the boilerplate code (namespace references, class and method declarations) - only the overridden method body. This is quite similar to what 'Rhino.DSL' does in Boo - a script is converted into overridden method body in a dynamically created class that inherits from some specified base type. Can you point me to some examples? Thanks a lot RG ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] StackOverflow in System.Array.Clear
lambalice, use #pragma indent ( https://github.com/rsdn/nemerle/wiki/Indentation-based-syntax ), it will save people a lot of time figuring out how to compile your sources. Regards, Nikita 2014-02-05 5:33 GMT+04:00 lambdalice marisac...@gmail.com: Hi Juan. Nemerle has the indentation syntax mode, isn't enabled by default. You have to give the -i option, and you can just use this shell script(if command ncc is in the path): ncc -i bf.n -r Nemerle.Compiler.dll -t:dll -o bf.dll ncc -i bfrun.n -r bf.dll https://github.com/lambdalice/MacroBF/blob/master/build.sh And please see the bfrun.n that contains brainf*ck codes: https://github.com/lambdalice/MacroBF/blob/master/bfrun.n All of the brainf*ck codes will be successfly compiled in Windows(and Mono for Windows), but Mono on Linux will give you the error. - 16 years old Japanese student -- View this message in context: http://mono.1490590.n4.nabble.com/StackOverflow-in-System-Array-Clear-tp4661845p4661850.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Size of thread in Mono (65MB per thread?)
The problem is that there is no anything simular to MEM_RESERVE and MEM_COMMIT from Windows (flags for VirtualAlloc/VirtualAllocEx), so there is no way to properly reserve a large block of virtual address space. BTW, windows threads reserve a lot of address space using MEM_RESERVE and then use SEH/VEH to detect, when memory should be commited, so it uses the same overcommit mechanics. You can create a lot of threads with large stacks, try to use it and get out of memory exception when, actually, trying to push something on your stack. 2013/12/21 james ja...@mansionfamily.plus.com On 20/12/2013 09:27, Marek Habersack wrote: Unix systems work based on a bit different principle than the Windows ones. Namely, as Nikita mentions in his other mail, the virtual memory is nearly free of any limits - your process reserves the right to use that much memory, but it doesn't actually use (commit) it physically. The virtual memory reservation is merely a hint of what can be consumed by the program, should it need it. I really think this ought to be challenged. No least because I recently ran into an issue on some production RedHat servers which had memory_overcommit set to '2'. Historically, UNIX systems DID behave like Windows. And some of them still do. They require that a request for VM can be satisfied from the free physical+virtual memory. The default is now to allow lazy programming that treats virtual address space as free, as you note - but the flip side is that programs can ask the OS for memory, be given it without error, and then find that they are summarily terminated if they try to use it. Or that some other process is summarily terminated. This mechanism came about in AIX first I believe, an Linux copied it. Solaris held out for a long time with 'proper' behaviour, I don't know whether it allows overcommit now. Whether or not you think allowing overcommit is a good idea is very much dependent on whether you think a good return from malloc should allow you to use the memory you just asked for. In fairness, the problem is typically worst in multi-threaded programs that can't handle segmented thread stacks - they have to reserve enough space for reasonable levels of stack depth and stack-local data so they have to reserve VM space to ensure that malloc doesn't place another block after the heap that's actually in use. Laziness is actually allocating the space and relying on the OS to allow overcommit and not actually back such memory until needed, rather than just reserving a VM range and allocating on fault. The prod servers I had showed no use of swap, about 6gig out of 32 physical in use (with the rest as buffers) - and thread starts and allocs were failing. Needless to say all the machines we'd used for dev, qa, and load testing had overcommit 0 and we got mugged as a result. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Size of thread in Mono (65MB per thread?)
In normal circumstances (i. e. physical machine, right type of virtualization, etc) virtual memory address space is almost free, so many applications reserve large amounts of it. However, until they really need that memory, no physical memory is used. OpenVZ and such solutions are using virtual memory limit (that's why you'll have problems using apache2 on 100MB OpenVZ VPS and it'll run fine on Xen/KVM with the same amount of memory). So the only thing you could do is changing your virtualization software. Try to play with mono runtime options, but I'm not sure that'll be effective. Regards, Nikits 2013/12/20 Nicolas Antoniazzi nicolas.antonia...@gmail.com I am not using OpenVZ but a solution that we developed based on Linux kernel calls because we really need to bootstrap a virtual environment in less than 50ms. I tested the same program on a .Net platform and after 1000 threads created, the whole application used 48MB of RAM. It sounds really strange to me that a Thread, that in theory should be a light process, takes 65MB of virtual memory. In the meantime, I am not expert in differences between virtual and physical memory, but, does your answer mean that if mono would detects that my system only has 500MB of physical memory, it would reserve less amount of memory per thread? Maybe there is a way to send some parameters to mono or to change some content in /proc to simulate a smaller amount of physical memory? Thanks for your answer! 2013/12/20 Nikita Tsukanov kek...@gmail.com Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization. Regards, Nikita 2013/12/19 Nicolas Antoniazzi nicolas.antonia...@gmail.com Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already consumed without the use of any thread. Is it a normal behavior? P.S: Sorry I double posted this message on mono-list because I did not understood that third party programmers also had to come on this devel list. Thanks! -- Nicolas Antoniazzi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Size of thread in Mono (65MB per thread?)
Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization. Regards, Nikita 2013/12/19 Nicolas Antoniazzi nicolas.antonia...@gmail.com Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already consumed without the use of any thread. Is it a normal behavior? P.S: Sorry I double posted this message on mono-list because I did not understood that third party programmers also had to come on this devel list. Thanks! -- Nicolas Antoniazzi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installing mono via copy
- set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installing mono via copy
You should install to the _same_ prefix you configured your sources. ./configure script hardcodes some paths based on prefix value and compiled code will expect to find needed files there. 2013/12/13 Andrés G. Aragoneses kno...@gmail.com /usr/local is the default prefix if you don't supply one. This is normally the standard in most open source projects and the motivation of it is not to conflict with software installed by packages (which goes to /usr instead). But given that you're in an embedded system I would just use the /usr prefix to prevent incompatibilities that normally arise when integrating software between /usr and /usr/local So to answer your question: yes, you still need to specify the prefix at configure time, but define a DESTDIR at installation time. Maybe this example script can clear any more doubts you have (it's used to create .deb packages): https://github.com/7digital/7digital-mono/blob/master/build-mono-package.bash On 13/12/13 20:08, Chris Tacke wrote: So if I make install DESTDIR /path/to/temp do I still need to install on the target at /usr/local (te default prefix), or will “anywhere” work? I assume the former, but am trying to understand. -Chris *From:*mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Nikita Tsukanov *Sent:* Friday, December 13, 2013 1:06 PM *To:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Installing mono via copy - set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com mailto: cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Should be fixed with
https://github.com/mono/mono/commit/a31b580fdcbaa9a8a16d59ffb12d04f5872f54e8
Please, try to compile a fresh version of mono and check if the issue is
still present.
2013/8/13 Nikita Tsukanov kek...@gmail.com
I've filled a bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=13933 (also increased thread
count from 2 to 10 to make it easier to reproduce the issue).
2013/8/12 Nikita Tsukanov kek...@gmail.com
Oh, great. I've got lockup and segfault (on different runs) with this
code:
static INancyEngine _engine;
public static void Main(string[] args)
{
var pool = new SmartThreadPool ();
var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
_engine = bt.GetEngine ();
for (int c=0; c2; c++)
new Thread (ThreadProc).Start ();
Thread.Sleep (-1);
}
static void ThreadProc ()
{
int crid = 0;
while (true) {
crid ++;
var resp = _engine.HandleRequest (
new Request (GET, /,
new Dictionarystring,
IEnumerablestring (),
RequestStream.FromStream (
new MemoryStream (), 0, 0), http, , 127.0.0.1));
resp.Response.Contents (new MemoryStream
());
Console.WriteLine (Request #{0} done,
crid);
}
}
It just uses nancyfx engine from 2 threads.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Hello.
I've reproduced the problem without ANY I/O only with NancyFx.
Following code leads to lock up:
class MainClass
{
public static void Main(string[] args)
{
var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
var engine = bt.GetEngine ();
int rid = 0;
while (true)
{
var crid = rid++;
ThreadPool.QueueUserWorkItem (_ =
{
var resp = engine.HandleRequest (
new Request (GET, /,
new Dictionarystring,
IEnumerablestring (),
RequestStream.
FromStream (new MemoryStream (), 0, 0), http, , 127.0.0.1));
resp.Response.Contents (new
MemoryStream ());
Console.WriteLine(Request #{0} done
, crid);
});
Console.WriteLine(Request #{0} added, crid
);
}
}
}
public class TestController : NancyModule
{
public TestController ()
{
Get [/] = _ = test;
}
}
It works fine with mono 2.10.8 from Ubuntu repos.
2013/8/8 Nikita Tsukanov kek...@gmail.com
I'm unable to reproduce the issue with HttpListener/Sockets alone. It
needs INancyEngine.ProcessReqiest() somewhere in request processing
pipeline. So I'm still investigating, what conditions are needed to
repoduce the bug (and I suspect that it doesn't have to do with I/O at all,
since it reproduces even with my hand-made send/recv sockets backend).
2013/8/7 Andrés G. Aragoneses kno...@gmail.com
If you're able to reproduce it with 3.3 and not with 2.10.x, you should
definitely open a bug report for it in http://bugzilla.xamarin.com/stating
[regression] in the bug summary.
Also, I would open a separate bug report for the segfault you're getting
when running with MONO_DISABLE_AIO (pasting the backtrace of the segfault,
with debug symbols installed).
On 07/08/13 14:02, Alfred Hall wrote:
Tried running it with sgen or boehm on 2.10? Worth trying both I think.
Also how about 3.3 (master) ?
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Wednesday 7th August 2013 12:54
*To:*
mono-devel-list@lists.ximian.**commono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
locking up on linux
I've rewritten my SCGI server to work with TPL directly instead of
using async/await to make it run on mono 2.10. Then I've tried to
run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
backend and to hammer it with jmeter. 500K requests without any
lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
Server source code is still on GitHub -
https://github.com/kekekeks/**scgi-sharphttps://github.com/kekekeks/scgi-sharp
2013/8/7 Greg Young gregoryyou...@gmail.com
mailto:gregoryyoung1@gmail.**com gregoryyou...@gmail.com
I believe attaching a debugger changes things like optimizations
from occurring (not positive but it does in clr)
On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just
debugging subsystem initialized i. e. if I launch this
program as a debugger it doesn't lock up.
publicstaticvoidMain(string[]**args)
{
intport=27042;
if(args.Length !=0)
port=int.Parse(args[0]);
while(true)
{
varvm= Mono.Debugger.Soft.**VirtualMachineManager.Listen(**
newIPEndPoint(IPAddress.**Loopback,port));
vm.Resume();
vm.Detach();
}
}
I'll use running with
--debugger-agent=transport=dt_**socket,address=
127.0.0.1:27042
http://127.0.0.1:27042 as a temporary workaround since
performance doesn't degrade a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool
itself. I've created socket layer implementation using
libevent (wrapped with Oars) and send/recv that utilizes
thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still
locks up after a while. Same behavior with debugger -
I'm unable to reproduce
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Oh, great. I've got lockup and segfault (on different runs) with this code:
static INancyEngine _engine;
public static void Main(string[] args)
{
var pool = new SmartThreadPool ();
var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
_engine = bt.GetEngine ();
for (int c=0; c2; c++)
new Thread (ThreadProc).Start ();
Thread.Sleep (-1);
}
static void ThreadProc ()
{
int crid = 0;
while (true) {
crid ++;
var resp = _engine.HandleRequest (
new Request (GET, /,
new Dictionarystring,
IEnumerablestring (),
RequestStream.FromStream (new
MemoryStream (), 0, 0), http, , 127.0.0.1));
resp.Response.Contents (new MemoryStream ())
;
Console.WriteLine (Request #{0} done, crid
);
}
}
It just uses nancyfx engine from 2 threads.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
I've filled a bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=13933(also increased
thread count from 2 to 10 to make it easier to reproduce
the issue).
2013/8/12 Nikita Tsukanov kek...@gmail.com
Oh, great. I've got lockup and segfault (on different runs) with this code:
static INancyEngine _engine;
public static void Main(string[] args)
{
var pool = new SmartThreadPool ();
var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
_engine = bt.GetEngine ();
for (int c=0; c2; c++)
new Thread (ThreadProc).Start ();
Thread.Sleep (-1);
}
static void ThreadProc ()
{
int crid = 0;
while (true) {
crid ++;
var resp = _engine.HandleRequest (
new Request (GET, /,
new Dictionarystring,
IEnumerablestring (),
RequestStream.FromStream (new
MemoryStream (), 0, 0), http, , 127.0.0.1));
resp.Response.Contents (new MemoryStream
());
Console.WriteLine (Request #{0} done,
crid);
}
}
It just uses nancyfx engine from 2 threads.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
I'm unable to reproduce the issue with HttpListener/Sockets alone. It needs
INancyEngine.ProcessReqiest() somewhere in request processing pipeline. So
I'm still investigating, what conditions are needed to repoduce the bug
(and I suspect that it doesn't have to do with I/O at all, since it
reproduces even with my hand-made send/recv sockets backend).
2013/8/7 Andrés G. Aragoneses kno...@gmail.com
If you're able to reproduce it with 3.3 and not with 2.10.x, you should
definitely open a bug report for it in http://bugzilla.xamarin.com/stating
[regression] in the bug summary.
Also, I would open a separate bug report for the segfault you're getting
when running with MONO_DISABLE_AIO (pasting the backtrace of the segfault,
with debug symbols installed).
On 07/08/13 14:02, Alfred Hall wrote:
Tried running it with sgen or boehm on 2.10? Worth trying both I think.
Also how about 3.3 (master) ?
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Wednesday 7th August 2013 12:54
*To:*
mono-devel-list@lists.ximian.**commono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
locking up on linux
I've rewritten my SCGI server to work with TPL directly instead of
using async/await to make it run on mono 2.10. Then I've tried to
run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
backend and to hammer it with jmeter. 500K requests without any
lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
Server source code is still on GitHub -
https://github.com/kekekeks/**scgi-sharphttps://github.com/kekekeks/scgi-sharp
2013/8/7 Greg Young gregoryyou...@gmail.com
mailto:gregoryyoung1@gmail.**com gregoryyou...@gmail.com
I believe attaching a debugger changes things like optimizations
from occurring (not positive but it does in clr)
On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just
debugging subsystem initialized i. e. if I launch this
program as a debugger it doesn't lock up.
publicstaticvoidMain(string[]**args)
{
intport=27042;
if(args.Length !=0)
port=int.Parse(args[0]);
while(true)
{
varvm= Mono.Debugger.Soft.**VirtualMachineManager.Listen(**
newIPEndPoint(IPAddress.**Loopback,port));
vm.Resume();
vm.Detach();
}
}
I'll use running with
--debugger-agent=transport=dt_**socket,address=
127.0.0.1:27042
http://127.0.0.1:27042 as a temporary workaround since
performance doesn't degrade a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool
itself. I've created socket layer implementation using
libevent (wrapped with Oars) and send/recv that utilizes
thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still
locks up after a while. Same behavior with debugger -
I'm unable to reproduce the issue when running under it.
I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably
affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono
compiled from master (with pull request #703
merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
Do you have our pull req? We are stable
after (and seriously read history of this
list)
On Tuesday, August 6, 2013, Nikita Tsukanov
wrote:
https://github.com/kekekeks/**scgi-sharphttps://github.com/kekekeks/scgi-sharp-
here is my SCGI server with host for
NancyFx. If you run Sandbox.exe with
--echo-server it will not use nancy
infrastructure and will respond
directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Huh, it doesn't require debugger to be _attched_, just debugging subsystem
initialized i. e. if I launch this program as a debugger it doesn't lock
up.
public static void Main (string[] args)
{
int port = 27042;
if (args.Length != 0)
port = int.Parse (args [0]);
while (true)
{
var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new IPEndPoint
(IPAddress.Loopback, port));
vm.Resume ();
vm.Detach ();
}
}
I'll use running with --debugger-agent=transport=dt_socket,address=
127.0.0.1:27042 as a temporary workaround since performance doesn't degrade
a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool itself. I've
created socket layer implementation using libevent (wrapped with Oars) and
send/recv that utilizes thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still locks up after a
while. Same behavior with debugger - I'm unable to reproduce the issue when
running under it. I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono compiled from master (with
pull request #703 merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
Do you have our pull req? We are stable after (and seriously read
history of this list)
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
https://github.com/kekekeks/scgi-sharp - here is my SCGI server with
host for NancyFx. If you run Sandbox.exe with --echo-server it will not use
nancy infrastructure and will respond directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081;
}
Now I'm looking for alternative socket library to use it as a
replacement for System.Net.Sockets.
2013/8/6 Greg Young gregoryyou...@gmail.com
Actually not that surprised we also found out file stream.flush(true)
only works sometimes and ms never back supported it to actually work :)
On Tuesday, August 6, 2013, Alfred Hall wrote:
**
Yeah you're having exactly the same issues as I am. I'm surprised others
haven't had this problem before. Not sure who works on this area of the
mono codebase these days. If you got a minimal test case it may be worth us
raising a Xamarin bug in bugzilla.
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Tuesday 6th August 2013 20:18
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking
up on linux
Running with mono from master haven't helped.
And I'm not sure what the hell is going on, but I cann't reproduce the
issue when running under... Monodevelop's debugger. It runs perfectly under
it, but when I try to run the same binary from console (even with --debug
option) it locks up or segfaults. Does anyone know what does it mean?
2013/8/6 Nikita Tsukanov kek...@gmail.com
Great. It locked up with my more complex logic.
Funny fact: NancyFx increases request processing time from 2ms to 70ms
with the same echo response.
Another funny fact: with MONO_DISABLE_AIO I've got segfault.
Now I'll try to use build patched mono. Not sure that it's the same
issue, because in my case it never tries to read and write simultaneously
on the same socket.
2013/8/6 Greg Young gregoryyou...@gmail.com
There are many cases the patch we provided does not affect eg no overlap
in io between send/receive
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Interesting... I've written a simple server using only
Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then
sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it
still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI
server logic from NetworkStream to Socket and see what will happen.
2013/8/6 Andrés G. Aragoneses kno...@gmail.com
On 06/08/13 18:42, Nikita Tsukanov wrote:
Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30
21:08:00 UTC 2013)
Mono 3.2.0 does *not* hav
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Ehm. Tried to run NancyFx with HttpListener on mono 2.10.8.1 (from ubuntu
repos) on my desktop machine. No lockups.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I've rewritten my SCGI server to work with TPL directly instead of using
async/await to make it run on mono 2.10. Then I've tried to run it with
mono 2.10.8.1 and mono 3.2 with System.Net.Sockets backend and to hammer it
with jmeter. 500K requests without any lockups on Mono 2.10, lockup at
22164th request on mono 3.2.
Server source code is still on GitHub -
https://github.com/kekekeks/scgi-sharp
2013/8/7 Greg Young gregoryyou...@gmail.com
I believe attaching a debugger changes things like optimizations from
occurring (not positive but it does in clr)
On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just debugging
subsystem initialized i. e. if I launch this program as a debugger it
doesn't lock up.
public static void Main (string[] args)
{
int port = 27042;
if (args.Length != 0)
port = int.Parse (args [0]);
while (true)
{
var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new
IPEndPoint (IPAddress.Loopback, port));
vm.Resume ();
vm.Detach ();
}
}
I'll use running with --debugger-agent=transport=dt_socket,address=
127.0.0.1:27042 as a temporary workaround since performance doesn't
degrade a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool itself. I've
created socket layer implementation using libevent (wrapped with Oars) and
send/recv that utilizes thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still locks up after a
while. Same behavior with debugger - I'm unable to reproduce the issue when
running under it. I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono compiled from master (with
pull request #703 merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
Do you have our pull req? We are stable after (and seriously read
history of this list)
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
https://github.com/kekekeks/scgi-sharp - here is my SCGI server with
host for NancyFx. If you run Sandbox.exe with --echo-server it will not use
nancy infrastructure and will respond directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081;
}
Now I'm looking for alternative socket library to use it as a
replacement for System.Net.Sockets.
2013/8/6 Greg Young gregoryyou...@gmail.com
Actually not that surprised we also found out file stream.flush(true)
only works sometimes and ms never back supported it to actually work :)
On Tuesday, August 6, 2013, Alfred Hall wrote:
**
Yeah you're having exactly the same issues as I am. I'm surprised others
haven't had this problem before. Not sure who works on this area of the
mono codebase these days. If you got a minimal test case it may be worth us
raising a Xamarin bug in bugzilla.
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Tuesday 6th August 2013 20:18
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking
up on linux
Running with mono from master haven't helped.
And I'm not sure what the hell is going on, but I cann't reproduce the
issue when running under... Monodevelop's debugger. It runs perfectly under
it, but when I try to run the same binary from console (even with --debug
option) it locks up or segfaults. Does anyone know what does it mean?
2013/8/6 Nikita Tsukanov kek...@gmail.com
Great. It locked up with my more complex logic.
Funny fact: NancyFx increases request processing time from 2ms to 70ms
with the same echo response.
Another funny fact: with MONO_DISABLE_AIO I've got segfault.
Now I'll try to use build patched mono. Not sure that it's the same
issue, because in my case it never tries to read and write simultane
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Hello. I've written a simple SCGI server, configured nginx to work with it,
hammered it with jmeter and... got the same issue. It works for a while and
then stops accepting new connections (some existing ones still waiting with
CLOSE_WAIT). I get it with new NetworkStream(TcpListener.AcceptSocket())
and BeginWrite/BeginRead. MONO_DISABLE_AIO actually helps it to survive for
20-30 more seconds but result is the same.
Now I'll try to use some alternative way of working with sockets, may be
libuv or something like that.
Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00
UTC 2013)
2013/8/5 Alfred Hall ah...@ahall.org
**
Getting similar issues when using FastCGI/XSP proxied via Nginx using tcp
and unix sockets (tried both). After hammering it with jmeter it ends up
locking up. I'm wondering if other mono webapps have this issue. Would be
useful if someone else here could do a similar loadtest using jmeter and
let me know if it happens to them.
-Original message-
*From:* Alfred Hall ah...@ahall.org
*Sent:* Sunday 4th August 2013 17:41
*To:* Nikita Tsukanov kek...@gmail.com; mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
on linux
Hi Nikita.
Full thread dump:
threadpool thread tid=0x0x7fc4ad29d700 this=0x0x7fc4ad584c70 thread
handle 0x80f state : not waiting owns ()
IO Threadpool worker tid=0x0x7fc4ad25c700 this=0x0x7fc4ad584dd0 thread
handle 0x810 state : interrupted state owns ()
IO Threadpool worker tid=0x0x7fc4a7567700 this=0x0x7fc4a741d350 thread
handle 0x845 state : interrupted state owns ()
Threadpool worker tid=0x0x7fc4ac39a700 this=0x0x7fc4a6192270 thread
handle 0x837 state : interrupted state owns ()
at unknown 0x
at (wrapper managed-to-native)
object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr)
0x
at (wrapper alloc) object.AllocVector (intptr,intptr) 0x
at System.Net.HttpConnection.BeginReadRequest () 0x0003a
at System.Net.EndPointListener.OnAccept (object,System.EventArgs)
0x00357
at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted
(System.Net.Sockets.SocketAsyncEventArgs) 0x0002e
at System.Net.Sockets.SocketAsyncEventArgs.AcceptCallback
(System.IAsyncResult) 0x00336
at System.Net.Sockets.SocketAsyncEventArgs.DispatcherCB
(System.IAsyncResult) 0x0010f
at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object
(object,intptr,intptr,intptr) 0x
I then tried the same again and only got this in my trace:
Full thread dump:
threadpool thread tid=0x0x7f31b8ac5700 this=0x0x7f31b8da4c70 thread
handle 0x80e state : not waiting owns ()
IO Threadpool worker tid=0x0x7f31b8a84700 this=0x0x7f31b8da4dd0 thread
handle 0x80f state : interrupted state owns ()
Not sure why I'm not getting any dump here. Any more debugging I can do on
there?
What seems to happen is its coping well initially with the requests and
then in all of a sudden it stops accepting connections and existing
connections dont die off.
Cheers,
Alf
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Sunday 4th August 2013 16:13
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
on linux
Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT {PID})
when it stops processing requests. It will force mono to write thread stack
traces to stdout. Grab them and post here, I suspect that the issue is
simular to one experienced by me.
2013/8/4 Nikita Tsukanov kek...@gmail.com
Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT
{PID}) when it stops processing requests. It will force mono to write
thread stack traces to stdout. Grab them and post here, I suspect that
the issue is simular to one experienced by me.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Interesting... I've written a simple server using only Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from NetworkStream to Socket and see what will happen. 2013/8/6 Andrés G. Aragoneses kno...@gmail.com On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Great. It locked up with my more complex logic. Funny fact: NancyFx increases request processing time from 2ms to 70ms with the same echo response. Another funny fact: with MONO_DISABLE_AIO I've got segfault. Now I'll try to use build patched mono. Not sure that it's the same issue, because in my case it never tries to read and write simultaneously on the same socket. 2013/8/6 Greg Young gregoryyou...@gmail.com There are many cases the patch we provided does not affect eg no overlap in io between send/receive On Tuesday, August 6, 2013, Nikita Tsukanov wrote: Interesting... I've written a simple server using only Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from NetworkStream to Socket and see what will happen. 2013/8/6 Andrés G. Aragoneses kno...@gmail.com On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Running with mono from master haven't helped. And I'm not sure what the hell is going on, but I cann't reproduce the issue when running under... Monodevelop's debugger. It runs perfectly under it, but when I try to run the same binary from console (even with --debug option) it locks up or segfaults. Does anyone know what does it mean? 2013/8/6 Nikita Tsukanov kek...@gmail.com Great. It locked up with my more complex logic. Funny fact: NancyFx increases request processing time from 2ms to 70ms with the same echo response. Another funny fact: with MONO_DISABLE_AIO I've got segfault. Now I'll try to use build patched mono. Not sure that it's the same issue, because in my case it never tries to read and write simultaneously on the same socket. 2013/8/6 Greg Young gregoryyou...@gmail.com There are many cases the patch we provided does not affect eg no overlap in io between send/receive On Tuesday, August 6, 2013, Nikita Tsukanov wrote: Interesting... I've written a simple server using only Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from NetworkStream to Socket and see what will happen. 2013/8/6 Andrés G. Aragoneses kno...@gmail.com On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
https://github.com/kekekeks/scgi-sharp - here is my SCGI server with host
for NancyFx. If you run Sandbox.exe with --echo-server it will not use
nancy infrastructure and will respond directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081;
}
Now I'm looking for alternative socket library to use it as a replacement
for System.Net.Sockets.
2013/8/7 Nikita Tsukanov kek...@gmail.com
https://github.com/kekekeks/scgi-sharp - here is my SCGI server with host
for NancyFx. If you run Sandbox.exe with --echo-server it will not use
nancy infrastructure and will respond directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081;
}
Now I'm looking for alternative socket library to use it as a replacement
for System.Net.Sockets.
2013/8/6 Greg Young gregoryyou...@gmail.com
Actually not that surprised we also found out file stream.flush(true)
only works sometimes and ms never back supported it to actually work :)
On Tuesday, August 6, 2013, Alfred Hall wrote:
**
Yeah you're having exactly the same issues as I am. I'm surprised others
haven't had this problem before. Not sure who works on this area of the
mono codebase these days. If you got a minimal test case it may be worth us
raising a Xamarin bug in bugzilla.
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Tuesday 6th August 2013 20:18
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking
up on linux
Running with mono from master haven't helped.
And I'm not sure what the hell is going on, but I cann't reproduce the
issue when running under... Monodevelop's debugger. It runs perfectly under
it, but when I try to run the same binary from console (even with --debug
option) it locks up or segfaults. Does anyone know what does it mean?
2013/8/6 Nikita Tsukanov kek...@gmail.com
Great. It locked up with my more complex logic.
Funny fact: NancyFx increases request processing time from 2ms to 70ms
with the same echo response.
Another funny fact: with MONO_DISABLE_AIO I've got segfault.
Now I'll try to use build patched mono. Not sure that it's the same
issue, because in my case it never tries to read and write simultaneously
on the same socket.
2013/8/6 Greg Young gregoryyou...@gmail.com
There are many cases the patch we provided does not affect eg no
overlap in io between send/receive
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Interesting... I've written a simple server using only
Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and
then
sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it
still responds with Lorem ipsum ... perfectly. I'll try to port my
SCGI
server logic from NetworkStream to Socket and see what will happen.
2013/8/6 Andrés G. Aragoneses kno...@gmail.com
On 06/08/13 18:42, Nikita Tsukanov wrote:
Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30
21:08:00 UTC 2013)
Mono 3.2.0 does *not* have Yuri's patch.
__**_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.**com
http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Le doute n'est pas une condition agréable, mais la certitude est
absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Hi there. I'm running the NancyFX web framework in self hosting mode which is using HttpListener which basically means I deploy an executable and run it and it will start a webserver on localhost on a TCP port of choice. I then use nginx to proxy to it. I first ran my executable on my macbook pro and bombarded it with jmeter and it coped fine and no issues. I then deployed on my debian wheezy 64 bit linux box running on top of KVM using mono 3.2.0 and performed the same jmeter experiment. It locks up fairly quickly and wont take any new requests. I've tried using both sgen and boehm but they behave similarly although it seems to lock up faster when using sgen. I also tried enabling MONO_DISABLE_AIO but it doesn't make any difference. Anyone had similar issues? I also experienced problems with HttpListener before (on Mono 2.6 and 2.10). Forcing mono to print stacktraces with SIGQUIT signal revealed the fact that HttpListener hungs somewhere in System.Net.HttpConnection.ProcessInput. But in my case it works pretty fine behind nginx. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT {PID})
when it stops processing requests. It will force mono to write thread stack
traces to stdout. Grab them and post here, I suspect that the issue is
simular to one experienced by me.
2013/8/4 Nikita Tsukanov kek...@gmail.com
Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT
{PID}) when it stops processing requests. It will force mono to write
thread stack traces to stdout. Grab them and post here, I suspect that
the issue is simular to one experienced by me.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building MonoDevelop 4.0.4 on Ubuntu Desktop 13.04
Hello Jesse. You need gnome-sharp packages in GAC and pkg-config. You can use my PPA ( https://launchpad.net/~keks9n/+archive/monodevelop-latest ) to obtain needed dependencies. Currently they are build for 12.10, but you can install them in 13.04 2013/4/29 JesseBuesking jessebuesk...@gmail.com I'm attempting to build MonoDevelop from the git source on Ubuntu Desktop 13.04, but I'm fairly certain I'm doing something wrong. I've got a script that builds each component, semi-closely following http://monodevelop.com/Developers/Articles/Building_MonoDevelop_on_Ubuntu, doing it as a parallel install (/opt/mono). When it gets to the point that it's compiling MonoDevelop, I always get an error for GnomePlatform.cs(29,7): error CS0246: The type or namespace name `Gnome' could not be found. Are you missing an assembly reference? I then noticed on http://www.mono-project.com/Parallel_Mono_Environments that one of the steps is to build gtk-sharp v 1.0.10. When I attempt to do so (from the git source), I get errors like art/Makefile.am:28: addprefix $(srcdir: non-POSIX variable name. Maybe someone that knows more can glance over my main install script (install_all.sh) and see if perhaps I'm using a conflicting package. I'm attempting to use the latest tag available for each project, so maybe there are known conflicts that I'm running into. Also, feel free to look over the rest of the installation scripts. At one point I was installing mono-tools and mono-addins from git, but then I noticed that when you git submodule in MonoDevelop it installs those. Thanks, Jesse Scripts: https://www.dropbox.com/sh/linv9ge6j08lyc7/6FWsZfirrC/monoinstall -- View this message in context: http://mono.1490590.n4.nabble.com/Building-MonoDevelop-4-0-4-on-Ubuntu-Desktop-13-04-tp4659544.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
