s/ok we have to because of failover/ok we have two because of failover/ On Wed, Aug 2, 2017 at 11:29 AM, Daniel Kozak <kozz...@gmail.com> wrote:
> On Fri, Jul 28, 2017 at 4:58 PM, Ali via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > >> While the Orgs using D page is very nice ... I hoping to hear more >> personal stories ... >> >> So >> >> How do you use D? >> > > Mainly at work, for lot of things. > > autoloader - tool for parsing all php files at our main project and > generate file for autoloading php files > esatd - deamon for controling and communicating with our servers > (reading logs, do releases of our products, controlling of availability...) > cronchecker - tool for managing and watchdoging our crons > dbsync - db tool for syncing and moving our databases around different > servers > testdbsync - dbtool sync our production databases to our test databases > phpdispatcher - deamon for managing php workers processes > camera-media-server - reverse engineering server for communicating > with some chinese DVR units > esat-map-engine - tool for (reverse) geocoding, and generating map > tiles > mapfactorbridge - REST API over MapFactor OCX(windows only, we used it > under wine), so it is possible to use it on many machines through network > and on any platform > MapfactorWrapper - demon for calculating shortest path from one > city(or any place) to another using mapfactor ocx api (mapfactorbridge) > > > >> >> Did you introduce D to your work place? How? What challenges did you face? >> > > Yes in 2012, only problem was with the ecosystem. There has been no good > IDE and too few libraries, but because of posibility to use C libraries it > was not a problem. > But good IDE is still a problem for some of us. > > >> >> What is you D setup at work, which compiler, which IDE? >> > > DMD for development, LDC or GDC for release binaries, VSCode with webfreak > dlang plugin (2017-now), monodevelop (2013-2016) > > >> >> And any other fun facts you may want to share :) >> > > In 2012 at work we have been looking for a way how to improve performance > of our data processing machines. These machines process lots of files > (binary,xml,text...). > These files comes from GPS units and has been (still are) process by PHP > scripts (called parsers). > > So we decided to rewrite those PHP scripts to something faster (PHP has > been quite slow theses days, now with PHP7 and HHVM it is little better). > So I was responsible for finding another language (the right one) in which > we wil rewrite those scripts. OK easy task, so I selected few languages I > know to select from. > Java, C/C++, Go, Python. But quite fast I realized none of these languages > fulfil our requirements. > Our requirements was: > OOP (Go is out) > GC (C++ is out, ok there is a way to use gc in c++, but i have never done > that before) > Fast startup (Java is out because of VM) > Syntax similar to PHP as much as posible (python is out) > Fast compilation (C++ is out again) > > Our best choice has been Java, but it would mean change architecture > (instead of executing own process for every file, we will need to process > them in one process with multiple threads or something similar), which has > been no go these days. > > So I have been looking for some another language. And for some reason I > have remembered that there has been some language, which I have try at my > high school days (2004-2008). Unfortunately I did not remembred the name. > So I start typing into google things I have remembred about this language. > And after some time I have found it (D language). So I looked at D closer > and was very satisfied. My first thoughts was something like "This is it". > > So I introduce D to my coworkers. At first there has been two camps. One > camp has the same feeling about D as me, the other ones was OK with D as a > language, but has been afraid of ecosystem. So I have started to showing > them how easily I can use C ecosystem so they do not have to be worried. So > after some time D has been chosen and we started to rewrite our parsers > into D. > > First results (just data processing) has been promising (new parsers has > been 10 to 100 times faster than the old(PHP) ones with smaller system > requirments), but after integrating other parts (database, filesystem...) > we have realized there is an almost no gain in the end. Data processing was > only small part of parsers, so database and filesystem interaction has been > the problem. So we start to improve this part of parsers. In the end we was > 5 times faster than the old parsers, but we could just do all these changes > to old parsers too. So we end up with rewriting our D parsers back to PHP, > because D parsers has been to far from being complete. > > But it was not complete failure. Because of this we have improved our > parsers and D has established in our ecosystem. After few years parsers > performance became problem again (even with PHP 7). So we need to improve > them again. We have already known that rewriting it to something faster > would not help. So I have try another approach. > > The result of that approach is phpdispatcher. So instead of starting new > process for every file request there is a D deamon (phpdispatcher) which > put file request into queue and assign them to php processes (workers). > Phpdispatcher and workers communicating through TCP, because of not > starting new php process every time, we can utilize caches (opcache...) > or JIT when HHVM is used. And we do not need to reestablish db connections > every time. > > So after phpdispatche has been moved to production, we was able to go from > five machines to only one (ok we have to because of failover) > >
